Security Requirements

The NIST Cybersecurity Framework (CSF) defines a taxonomy of high-level cybersecurity outcomes any organization should meet. The table below outlines the Functions, Categories, and Subcategories of the CSF Core. Each category contains multiple outcomes within them.

Function	Category	Category Identifier
Govern (GV)	Organizational Context	GV.OC
	Risk Management Strategy	GV.RM
	Roles, Responsibilities, and Authorities	GV.RR
	Policy	GV.PO
	Oversight	GV.OV
	Cybersecurity Supply Chain Risk Management	GV.SC
Identify (ID)	Asset Management	ID.AM
	Risk Assessment	ID.RA
	Improvement	ID.IM
Protect (PR)	Identity Management, Authentication, and Access Control	PR.AA
	Awareness and Training	PR.AT
	Data Security	PR.DS
	Platform Security	PR.PS
	Technology Infrastructure Resilience	PR.IR
Detect (DE)	Continuous Monitoring	DE.CM
	Adverse Event Analysis	DE.AE
Respond (RS)	Incident Management	RS.MA
	Incident Analysis	RS.AN
	Incident Response Reporting and Communication	RS.CO
	Incident Mitigation	RS.MI
Recover (RC)	Incident Recovery Plan Execution	RC.RP
	Incident Recovery Communication	RC.CO

The specific CSF outcomes the CAHN system should help an organisation meet are as follows:

IDENTIFY (ID): The organization’s current cybersecurity risks are understood

Asset Management (ID.AM): Assets (e.g., data, hardware, software, systems, facilities, services, people) that enable the organization to achieve business purposes are identified and managed consistent with their relative importance to organizational objectives and the organization’s risk strategy

• ID.AM-01: Inventories of hardware managed by the organization are maintained

Risk Assessment (ID.RA): The cybersecurity risk to the organization, assets, and individuals is understood by the organization

• ID.RA-01: Vulnerabilities in assets are identified, validated, and recorded

PROTECT (PR): Safeguards to manage the organization’s cybersecurity risks are used

Identity Management, Authentication, and Access Control (PR.AA): Access to physical and logical assets is limited to authorized users, services, and hardware and managed commensurate with the assessed risk of unauthorized access

• PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization
• PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions
• PR.AA-03: Users, services, and hardware are authenticated
• PR.AA-04: Identity assertions are protected, conveyed, and verified
• PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties

Technology Infrastructure Resilience (PR.IR): Security architectures are managed with the organization’s risk strategy to protect asset confidentiality, integrity, and availability, and organizational resilience

• PR.IR-01: Networks and environments are protected from unauthorized logical access and usage

Data Security (PR.DS): Data are managed consistent with the organization’s risk strategy to protect the confidentiality, integrity, and availability of information

• PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected
• PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected

DETECT (DE): Possible cybersecurity attacks and compromises are found and analyzed

Continuous Monitoring (DE.CM): Assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events

• DE.CM-01: Networks and network services are monitored to find potentially adverse events

Requirements

The following are the architecture components of the CAHN prototype, their function and the CSF outcomes they support.

Architecture Component	Component	Component’s Function	Function’s Relationships to CSF Outcomes	Relationship Explanation
Device Manufacturer and Factory Provisioning	TrustNetZ MPR Manufacturer Provisioning Root (MPR)	A manufacturer CA service. The MPR provides the manufacturer signing function and is involved in the provisioning of the signed IDevID. It maintains a record of each device created	Supports (example of) ID.AM-01: Inventories of hardware managed by the organization are maintained	Device serial number and IDevID certificate and device model type are recorded during the provisioning process.
			Supports (integral to) PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization	The MPR signs the self-provided identity in the pledge’s CSR request. The signed birth certificate is recorded by the manufacturer and returned back to the pledge for secure storage
			Supports (example of) PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties	Device intent, in the form of MUD URL is optionally inserted into the IDevID certificate before signing. But there other methods available to infer device intent.
			Supports (integral to) PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions	The private key of the IDevID is generated on the TPM attached to the device before the factory provisioning CSR is issued for the certificate that will be bound to the device’s identity. The private key never leaves the TPM boundary.
Supply Chain Integration Service	TrustNetZ MASA,	The MASA provides the operational manufacturer authorization service, as part of the network onboarding flow	Supports (precedes) ID.AM-01: Inventories of hardware managed by the organization are maintained	Bootstrapping information (e.g., an 802.1AR certificate) for each of the devices that the manufacturer creates must be provided to the domain registrar of the device owner and correlated with the devices in the owner’s inventory information so the owner will be able to authenticate the devices. In addition, information regarding which entity owns a device may be recorded in the MASA .
			Supports (precedes) PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization	The generation and transfer of device bootstrapping information (e.g., device certificate information) from the device manufacturer to the device owner must occur before the device’s identity can be cryptographically authenticated during network-layer onboarding to the device owner’s network. A trusted MASA generates a signed voucher attesting to device authenticity assertions.
Network-Layer Onboarding Component	Stateful, non-persistent Linux app that has two functional interfaces for both BRSKI and for the Authentication Service.	Runs the BRSKI protocol modified to work over Wi-Fi and acts as a BRSKI Domain Registrar. It authenticates the IoT device, receives a voucher request from the IoT device, and passes the request to the MASA. It also receives a voucher from the MASA, verifies it, and passes it to the IoT device. Assuming the IoT device finds the voucher to be valid and determines that the network is authorized to onboard it, the Domain Registrar provisions network credentials to the IoT device using EST.	Supports (integral to) PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization	The domain registrar is responsible for providing authenticated, authorized devices with a network-layer credential.
			Supports (integral to) PR.AA-03: Users, services, and hardware are authenticated	The domain registrar authenticates the IoT device.
			Supports (integral to) PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties	The domain registrar helps ensure that only authenticated, authorized devices are provided with the credentials that provide them access to the network. It enforces the organization's authorization policies, which may incorporate the principles of least privilege and separation of duties.
			Supports (integral to) PR.IR-01: Networks and environments are protected from unauthorized logical access and usage	Only devices that have network-layer credentials are permitted to connect to the network securely. The network-layer onboarding component is responsible for ensuring that only authenticated, authorized devices are provided with network-layer credentials, and it provides those credentials in a trusted fashion that protects their confidentiality and helps prevent them from being used by unauthorized devices.
			Supports (integral to) PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions	The domain registrar authenticates an IoT device’s identity by using the device’s public key to verify that the device’s private key is installed on the device.
			PR.AA-03 (already listed)	The domain registrar authenticates the IoT device.
			Supports (integral to) PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected	The domain registrar establishes an encrypted channel with the IoT device to ensure the confidentiality of information they exchange (e.g., the device’s network-layer credentials).
Access Point, Router, or Switch	Raspberry Pi 4B equipped with USB Wi-Fi dongle running TrustNetZ router management	Router, providing an open Wi-Fi network and a closed Wi-Fi network, interfacing with policy engine and event handler	Supports (example of) PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties	The device will not be permitted to connect to the network unless it presents the network-layer credentials that have been provisioned to is during the onboarding process.
Network-Layer Onboarding Authorization Service	Linux application on a PC which is running TrustNetZ policy engine	Determines whether the device is authorized to be onboarded to the network by checking if the device meets the policy requirements to be onboarded.	Is supported by (example of) ID.AM-01: Inventories of hardware managed by the organization are maintained	The certificate for each of the devices that the manufacturer creates is generated and stored by the MPR. The domain registrar relies on the MASA to approve the device’s claim that it was manufactured by the manufacturer. When the device attempts to onboard onto the network, the network adds the manufacturer and device to its database via a verifiable credential claim. In order for the device to pass the policy checks and be onboarded, the registrar must have a record of the device, manufacturer, device type, SBOM, vulnerability score and device owner.
IoT Device	Raspberry Pi devices running TrustNetZ BRSKI pledge agent	The IoT device that is used to demonstrate trusted network- and application-layer onboarding.	Is supported by (example of) ID.AM-01: Inventories of hardware managed by the organization are maintained	The organization must have an inventory of the devices that support BRSKI onboarding so it knows which devices to use in cases in which it wants to use this protocol to perform trusted network-layer onboarding.
			Supports (integral to) PR.AA-03: Users, services, and hardware are authenticated	The IoT device may authenticate the network before permitting itself to be onboarded to the network. The IoT device also permits itself to be authenticated as part of the network-layer onboarding process.
			Supports (integral to) PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected	The IoT device establishes an encrypted channel with the domain registrar to ensure the confidentiality of all information they exchange (e.g., the device’s network-layer credentials). If application-layer onboarding is also supported, the IoT device establishes an encrypted channel with the application-layer service to ensure confidentiality of information exchanged (e.g., the device’s application-layer credentials).
Secure Storage	Infineon Optiga™ SLB 9670 TPM 2.0 on the GeeekPi board, integrated with the pledge.	Storage on the IoT device that is designed to be protected from unauthorized access and capable of detecting attempts to hack or modify its contents. Used to store and process private keys and provide signing functions	Supports (integral to) PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization	The confidentiality provided to a device’s private key and credentials by storing and using them in secure storage is essential to ensuring that the device’s identity can be uniquely authenticated.
			Supports (integral to) PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions	The device’s private key, which serves as its birth credential along with its 802.1AR certificate (IDevID), is installed in secure storage within the device, this binds the device to its credential.
			Supports (integral to) PR.DS-01: The confidentiality, integrity, and availability of data-at-rest are protected	Information stored in secure storage is protected from unauthorized access and disclosure.
Certificate Authority (CA) used by the BRSKI Factory Provisioning Process	Manufacture CA, implemented as cloud service (locally simulated for demonstration)	The Manufacturer CA is used within the BRSKI factory provisioning process that is a precondition for Build 5 network-layer onboarding. The Manufacturer CA is used by the MPR to sign and issue IDevIDs to IoT devices.	Supports (integral to) PR.AA-02: Identities are proofed and bound to credentials based on the context of interactions	The device credential is an 802.1AR certificate (e.g., an IDevID) that is signed by a CA, so this certificate binds the device’s credential to the device’s identity. Also, all vouchers exchanged as part of the protocol are signed, enabling claims regarding device ownership to be verified. Also, the pledge and domain registrar create and sign voucher requests using their certificates, which in turn were signed by the CA.
Certificate Authority (CA) used by Build 5 During Network-Layer Onboarding	BRSKI Domain CA, implemented within the TrustNetZ network onboarding component, running as a Linux daemon process.	The domain CA issues and signs the LDevID certificate to represent permissioned network access.	Supports (example of) PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization	Network-layer credentials (LDevIDs) provisioned by BRSKI that are signed by the trusted domain CA can be verified and revoked.
Continuous Authorization Service	The Continuous Authorization Service, is implemented by the TrustNetZ policy engine	Performs a set of ongoing, policy-based continuous assurance and authorization checks on the device after it has connected to the network. The evaluated policy is configurable and uses all information available to the policy engine. The result of the policy evaluation is communicated downstream through network commands to the attached router(s)		The assurance policy engine periodically evaluates the security posture of each connected device using all information available. Vulnerabilities are formally enumerated, by discovering the device’s software bill of materials (SBOM), enumerating each attribute of the device’s common platform environment (CPE) well-formed name (WFN), then enumerating each common vulnerabilities and exposures (CVE) identifier associated with each CPE WFN.A threshold function is then applied to the aggregate CPEs to determine whether action is deemed necessary.
				The policy engine computes the aggregate CVE list. It uses the common vulnerability scoring system (CVSS) severity and score attributes, combined with other data to inform risk assessment.
				Risk responses are computed by the policy engine. All responses are logged.
				A baseline of allowed network operations can be modelled within the policy engine. Examples are a) a superset of verified MUD description b) an allow list of permitted IP addresses c) a deny list of suspicious IP addresses
				The CA policy engine is flexible by design and can use any public or proprietary information as deemed appropriate by the network owner. The demonstrated build uses: • Device type database • MUD descriptors. • SBOM database • CVE look up services • IP deny lists • Installation databases It additionally consumes network events.
				Within the CA policy engine we can express different thresholds. The demonstrated build includes a configurable CVE severity threshold.
				Devices which surpass the risk threshold defined by the policy engine can be contained by (a) revoking the EAP-TLS certificate, which removes it from the network (demonstrated) b) placing the device on a constrained subnet (possible but not demonstrated)